_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

• Generate coding plan for human review comments

• X
• Mastodon
• Reddit
• LinkedIn

• .changeset/lucky-jokes-change.md
  • Added a new changeset file to document the integration of GCP KMS for the allower functionality.
• .changeset/silly-yaks-divide.md
  • Added a new changeset file to document the feature of poking accounts after KYC completion.
• .do/app.yaml
  • Added new environment variables for GCP KMS configuration, including key ring, key version, project ID, and base64 encoded JSON credentials.
• cspell.json
  • Added 'valora' to the custom spelling dictionary.
• server/hooks/activity.ts
  • Removed unused ABI imports and the withRetry utility from viem.
  • Updated the import path for keeper to the new ../utils/accounts module.
  • Renamed accounts variable to accountLookup for clarity in database queries.
  • Modified the logic for processing transfers, replacing pokes map with a Set of accounts.
  • Refactored the account creation and poking logic to use the new keeper.poke function, simplifying asset handling and error management.
• server/hooks/block.ts
  • Updated the import path for keeper to the new ../utils/accounts module.
• server/hooks/panda.ts
  • Updated the import path for keeper to the new ../utils/accounts module.
• server/hooks/persona.ts
  • Imported firewallAddress from @exactly/common/generated/chain.
  • Imported allower and keeper from the new ../utils/accounts module.
  • Added a getAllower function to lazily initialize the allower client.
  • Integrated allower().then((client) => client.allow(account)) call after risk assessment to allow the account through the firewall.
  • Added a keeper.poke call after KYC to update account assets with a notification.
  • Refactored the addCapita call to directly use the parsed account address, removing the safeParse check.
• server/package.json
  • Added @google-cloud/kms as a dependency.
  • Added @valora/viem-account-hsm-gcp as a dependency.
• server/script/openapi.ts
  • Added stub environment variables for GCP KMS configuration.
• server/test/api/card.test.ts
  • Updated the mock import from ../mocks/keeper to ../mocks/accounts.
• server/test/e2e.ts
  • Updated the mock import from ../mocks/keeper to ../mocks/accounts.
• server/test/hooks/activity.test.ts
  • Updated the mock import from ../mocks/keeper to ../mocks/accounts.
  • Removed the test case for capturing 'no balance' errors after retries.
  • Adjusted captureException expectation to be more general.
  • Added anvilClient.setBalance calls to various tests to ensure sufficient balance for transactions.
  • Replaced exaSend spy with pokeSpy for keeper interactions.
  • Added a new test case to verify poke is called with the correct ignore option.
• server/test/hooks/block.test.ts
  • Updated the mock import from ../mocks/keeper to ../mocks/accounts.
• server/test/hooks/panda.test.ts
  • Updated the mock import from ../mocks/keeper to ../mocks/accounts.
• server/test/hooks/persona.test.ts
  • Added mocks for accounts and firewallAddress.
  • Updated afterEach hook to restore all mocks.
  • Updated persona signature header in test payloads.
  • Added tests for poking assets when balances are positive, poking only ETH, skipping WETH when ETH balance is positive, and not poking when balances are zero.
  • Added a test case to verify error handling when the firewall call fails.
  • Added a mock for panda.createUser in the manteca template test.
• server/test/mocks/accounts.ts
  • Renamed server/test/mocks/keeper.ts to server/test/mocks/accounts.ts.
  • Updated the mock to include allower and keeper from the new accounts module.
  • Configured allower mock to resolve with an allow function.
• server/test/utils/accounts.test.ts
  • Renamed server/test/utils/keeper.test.ts to server/test/utils/accounts.test.ts.
  • Updated imports to reference the new accounts mock and module.
  • Updated type imports to use @exactly/common/validation for Hash.
• server/test/utils/gcp.test.ts
  • Added a new test file to verify GCP credentials security, including file creation with secure permissions and early return for existing credentials.
• server/utils/accounts.ts
  • Added a new file to define keeper and allower wallet clients.
  • Implemented extender function to add poke functionality to the wallet client, handling ETH and ERC20 asset poking based on balances.
  • Implemented withExaSend function for robust transaction sending with Sentry tracing, error handling, and nonce management.
  • Integrated GCP KMS for the allower client, including credential initialization and retry logic for KMS errors.
  • Defined getAccount to retrieve a local account from GCP HSM.
• server/utils/gcp.ts
  • Added a new file to manage GCP credentials, including base64 decoding and secure file writing.
  • Implemented initializeGcpCredentials to ensure GCP service account credentials are set up securely.
  • Added hasCredentials to check for the existence of the credentials file.
  • Provided isRetryableKmsError to identify transient KMS errors for retry mechanisms.
• server/utils/keeper.ts
  • Removed the file, as its functionality has been refactored into server/utils/accounts.ts.
• server/vitest.config.mts
  • Added GCP KMS related environment variables for Vitest testing.

• The pull request introduces new functionality and refactors existing code, indicating active development.
• New changeset files were added, suggesting that these changes are intended for release notes.
• Extensive test updates and additions were made, reflecting thorough testing of the new allower and refactored accounts modules.

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

@@            Coverage Diff             @@
##             main     #839      +/-   ##
==========================================
- Coverage   71.23%   71.10%   -0.13%     
==========================================
  Files         212      213       +1     
  Lines        8378     8525     +147     
  Branches     2741     2783      +42     
==========================================
+ Hits         5968     6062      +94     
- Misses       2132     2165      +33     
- Partials      278      298      +20     

Flags with carried forward coverage won't be shown. Click here to find out more.

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

server/utils/accounts.ts, line 155
market may be null at the type level in args

assetsToPoke is typed as { asset: Address; market: Address | null }[]. When destructured at line 136, TypeScript sees market as Address | null in both branches of the ternary (lines 145–156). The else branch passes args: [market] to exaSend, where null is not a valid Address.

At runtime this is safe — only ETH entries have market: null and they take the pokeETH branch (line 149) — but TypeScript does not narrow market based on the asset !== ETH check. A future refactor that changes how assetsToPoke is populated could silently introduce a null address being sent on-chain, and the failure would be swallowed inside the outer Promise.allSettled (line 135).

Consider asserting non-null at the call site to make the invariant explicit:

                  : {
                      address: accountAddress,
                      abi: combinedAccountAbi,
                      functionName: "poke",
                      // eslint-disable-next-line @typescript-eslint/no-non-null-assertion
                      args: [market!],
                    },

Or narrow the type at build time by storing ETH entries and market entries in separate arrays.

server/utils/gcp.ts, line 37
Stale initializationPromise after credentials file deletion

initializationPromise is cached after the first successful initialization. If the credentials file is later removed at runtime (e.g., OS /tmp cleanup, systemd-tmpfiles, long-running container with volatile /tmp), every subsequent call to initializeGcpCredentials() returns the cached resolved promise without attempting to recreate the file.

Downstream in getAccount():

await initializeGcpCredentials();       // returns cached no-op promise
if (!(await hasCredentials())) throw …  // file is gone → always throws

The server cannot recover without a full restart. The resetGcpInitialization() export exists but is never called automatically, leaving allower() unable to recover from runtime credential file loss.

Suggested fix: Call resetGcpInitialization() inside getAccount() if hasCredentials() returns false after initialization resolves, allowing the next attempt to re-decode and re-write the credentials file:

export async function getAccount(): Promise<LocalAccount> {
  await initializeGcpCredentials();
  if (!(await hasCredentials())) {
    resetGcpInitialization(); // allow next caller to retry
    throw new Error(…);
  }
  …
}

server/utils/accounts.ts, line 63
Module-level GCP validation breaks keeper when GCP is unavailable

These GCP env-var checks run at module import time, before any GCP-dependent code is invoked. keeper (defined at line 65) is a plain private-key wallet client with no GCP dependency. Any hook that imports keeper (activity.ts, block.ts, panda.ts, etc.) will now fail to start if GCP_PROJECT_ID, GCP_KMS_KEY_RING, or GCP_KMS_KEY_VERSION are absent — even in environments or unit tests where the allower is not used.

This breaks the deployment of unrelated features if GCP credentials are not configured, and makes testing hooks that use keeper harder in isolated environments.

Suggested fix: Move the GCP env-var validation inside getAccount(), which is the only function that actually requires them:

export async function getAccount(): Promise<LocalAccount> {
  if (!process.env.GCP_PROJECT_ID) throw new Error("GCP_PROJECT_ID is required");
  const projectId = process.env.GCP_PROJECT_ID;
  if (!/^[a-z][a-z0-9-]{4,28}[a-z0-9]$/.test(projectId)) {
    throw new Error("GCP_PROJECT_ID must be a valid GCP project ID format");
  }
  // … validate GCP_KMS_KEY_RING and GCP_KMS_KEY_VERSION here too
  await initializeGcpCredentials();
  …
}

This keeps keeper importable regardless of GCP configuration and surfaces the error at the point of use.

server/utils/accounts.ts, line 161
Bitwise left-shift overflow in retry delay

1 << count uses a 32-bit signed integer operation. For count >= 31, the result wraps to a negative number (1 << 31 = -2147483648), which would produce a large negative delay and cause immediate (potentially infinite) retries without any back-off. With retryCount: 10 the current cap of count = 9 avoids the overflow, but this is a silent footgun if retryCount is ever raised.

Prefer the explicit exponentiation operator instead:

            delay: ({ count }) => Math.trunc(2 ** count) * 60,

server/utils/gcp.ts, line 4
DECODING_ITERATIONS magic number is undocumented

The triple base64 decode (DECODING_ITERATIONS = 3) is an unusual encoding strategy that will silently produce a corrupted credentials file if GCP_BASE64_JSON is encoded with a different iteration count (e.g., a single base64 encode as would be typical). There is no comment explaining why three iterations are required, and the only clue is hidden in the config-level test value.

Consider adding a comment to the constant (and possibly the app.yaml instructions) documenting the expected encoding:

// Credentials are stored triple-base64-encoded (base64(base64(base64(json)))) to survive
// shell/environment variable escaping layers. Ensure GCP_BASE64_JSON is encoded accordingly.
const DECODING_ITERATIONS = 3;

server/utils/accounts.ts, line 72
keeper onFetchRequest handler lacks error handling unlike allower

The allower client's onFetchRequest wraps captureRequests in a try/catch and logs failures with captureMessage (lines 385-394). The keeper client's handler does not — if clone.json() or parse(Requests, …) throws (e.g., malformed RPC batch payload), the error propagates out of the transport hook and can unexpectedly fail the entire RPC call.

      async onFetchRequest(request) {
        try {
          const clone = request.clone();
          captureRequests(parse(Requests, await clone.json()));
        } catch (error: unknown) {
          captureMessage("failed to parse or capture rpc requests", {
            level: "error",
            extra: { error },
          });
        }
      },